Artifact: Analysis Class

Analysis Class	Analysis classes represent an early conceptual model for æthings in the system which have responsibilities and behaviorÆ.
UML representation:	Class, stereotyped as ½boundary╗, ½entity╗ or ½control╗.
Worker:	Designer
More information:	Guidelines: Analysis Class Checkpoints: Analysis Classes
Purpose Properties Timing Responsibility Tailoring

Input to Activities:

Identify Design Elements

Identify Design Mechanisms

Output from Activities:

Use-Case Analysis

Purpose

Analysis classes are used to capture the major "clumps of responsibility" in the system. They represent the protoypical classes of the system, and are a 'first-pass' at the major abstractions that the system must handle. Analysis classes may be maintained in their own right, if a "high-level", conceptual overview of the system is desired. Analysis classes also give rise to the major abstractions of the system design: the design classes and subsystems of the system.

Properties

Property Name	Brief Description	UML Representation
name	the name of the class	attribute
description	a brief description of the role of the class in the system	attribute
responsibilities	a listing of the responsibilities of the class	attribute
attributes	the attributes of the class	attribute

Timing

Analysis classes are identified primarily in the Elaboration Phase, as Use Cases are analyzed. Some Analysis Classes may be identified as late as the Construction Phase, for Use Cases which are not analyzed until the Construction Phase.

Responsibility

A designer is responsible for the integrity of the analysis class, ensuring that:

Tailoring

The analysis classes, taken together, represent an early conceptual model of the system. This conceptual model evolves quickly and remains fluid for some time as different representations and their implications are explored. Formal documentation can impede this process, so be careful how much energy you expend on maintaining this æmodelÆ in a formal sense; you can waste a lot of time polishing a model which is largely expendable. Analysis classes rarely survive into the design unchanged. Many of them represent whole collaborations of objects, often encapsulated by subsystems.

Usually, simple note-cards, such as the example below, are sufficient (this is based on the well-known CRC Card technique). On the front side of the card, capture the name and description of the class. An example for a Course in a course registration system is listed below:

Class Name	Course
Description	The Course is responsible for maintaining information about a set of course sections having a common subject, requirements and syllabus.
Responsibilities	To maintain information about the course.
Attributes	Description	Type
Course Title	The name of the course	string
Description	A short description of the course	string

There is one analysis class card for each class discovered during the use-case-analysis workshop.